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DETAILED ACTION 

1 . Applicant filed a request for reconsideration (see Paper #30) with arguments 
directed at examiner's rejection (see Paper #29) of claims 1-14 and 29-44 as presented 
in amendment E (see Paper #20). 

2. This Office Action maintains the rejection (see Paper #29) of the claims as 
presented in applicant's amendment E filed 04/05/2001 (see Paper #20). This Office 
Action is responding to applicant's arguments (see Paper #30) which were presented in 
response to the non-final rejection presented in paper #29. 

3. The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action (see Paper No. 2), or will be included here for clarity, as 
necessary. The text of those sections of Title 35, U.S. Code not otherwise provided in a 
prior Office action will be included in this action where appropriate. 

4. Claims 1-14 and 29-44 have been examined. 

Claim Rejections - 35 USC § 103 

5. Claims 1-14 and 29-44 were rejected in Paper #29 under 35 U.S.C. 103(a) as 
being unpatentable over Talati et al. (U.S. Patent No. 5,903,878) hereafter referred to 
as Talati, and further in view of Wiecha (U.S. Patent No. 5,870,717). Examiner 
maintains this rejection as indicated below 



# 
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6. Claims 1-14, 29-35, and 37-44 are rejected in Paper #29 under 35 U.S.C. 103(a) 
as being unpatentable over Talati et al. (U.S. Patent No. 5,903,878) hereafter referred 
to as Talati, and further in view of Wiecha (U.S. Patent No. 5,870,717) and Official 
Notice. 

Claim 1: Talati discloses: 

transmitting an order for a product in response to an input by a user to said 
server through a communication network (col. 3 lines 4-21); 
receiving trading information including: 
— an e-mail address (col. 8 lines 62-67; col. 9 lines 1-11); 

a trading identifier associated with said order (col. 3 lines 4-19; col. 6 lines 
1-32; col. 7 lines 25-63; col. 8 lines 29-33); 

data on the contents of said order (col. 3 lines 12-19); and 
storing said trading information when said e-mail address coincides with 
an address of said server to which said order was transmitted (fig. 12 [331 , 335, 340]); 

receiving from said communication network trading processing information 
including: 

an e-mail address (col. 9 lines 45-59); 

a present status of processing for processing initiated for said order, as 
disclosed by Talati through the functionality of: 



\ 
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(col. 1 1 lines 38-51 ) there is illustrated an exchange of information 

between an 

originator 50 and a recipient 55 using an e-mail delivery system 305. 
Information is synonymous with document, software, classified data, transaction 
data or a database query and responses. The invention provides a method to 
securely exchange and process information between originator 50 and recipient 
55, where an originator and recipient can be client or server on the 
Internet/Intranet or private network. 

(col 1 1 lines 51-65) While the following is described with respect 
to an e-mail delivery system it should be realized that any type of delivery system 
would be useful. The originator 50 sends a document including a UTID and 
originator identifier (OID) to recipient 55 within an e-mail message at 430. Upon 
receipt of the e-mail message, the recipient 55 forwards another e-mail message 
to the transaction administrator (TA) 60 at 435. The e-mail message includes the 
OID, UTID and document name. The TA 60 authenticates the OID of originator 
so a message can be transmitted to the originator. If OID does not authorize, the 
TA 60 sends a negative response to recipient 55 at 450. Otherwise, the TA 60 
requests originator 50 to validate the transaction via another e-mail message at 
440. The e-mail message includes the UTID. 

— (col. 1 1 line 66 - col. 12 line 8) The originator 50 validates 
transactions by comparing UTID with a list 100, including UTIDs generated by 
the originator along with associated information. The originator 50 sends a 
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negative acknowledgment due to failure to match a UTID or associated 
information if the transaction is invalid or a positive acknowledgment if the 
transaction is valid and the UTID and associated information matches at 445. 
The TA 60 upon receipt of a positive or negative validation of the transaction with 
the associated UTID notifies the recipient of a positive status at 450. 

(col. 5 line 50 - col. 6 line 60) verifying and validating various steps 
of transactions; 

(col. 8 line 62 - col. 9 line 1 1 ) A format of an e-mail record 330 is 
more fully described in FIG. 12 wherein there is shown an e-mail record 330 
including the unique transaction identifier or message id 331; a mail type 
identification 335 indicating whether the record is to be transmitted, was just 
received, has already been transmitted, or comprise a transaction e-mail; the 
recipient's address 340; the subject matter of the e-mail 345; and the contents of 
the e-mail 348. For simplicity, the mail type identification 335 identifies the state 
of the e-mail record as it relates to the state of the e-mail delivery system 305. 
For example, when a user creates an e-mail record, the ECS 300 deposits this 
e-mail record into the mailbox database 315 with mail "type" equal to 1 indicating 
that the e-mail record is ready to be delivered to the recipients. The recipient 
address 340, subject matter 345 and contents 348 provide routing and content 
information to the e-mail delivery system 305. 

(col. 3 lines 4-59): 
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— A validated transaction is a transaction in which the TA validates 
the entities, facilitates the transaction and/or validates the contents of the 
transaction by the originator. In a validated electronic commerce transaction, 
either the client, merchant or transaction administrator can initiate the 
transaction. In a purchase transaction, the client initiates a transaction 
requesting particular items of merchandise or services from a merchant via the 
Internet, a dial-up-network, or any suitable network. The electronic transaction 
includes details of the transaction such as descriptions of the item(s) that the 
client desires to purchase, credit card or check payment information, information 
on other types of payment by means of which the item(s) will be purchased, and 
a unique transaction identifier that has been generated by the originator and is 
uniquely associated with the particular purchase transaction. 

— This information is transmitted to the merchant over the network. In 
response to the purchase order, the merchant generates a payment authorization 
request for transmission to the TA. The payment authorization request will have 
attached to it the unique transaction identifier initially provided by the client along 
with transaction information. Upon receipt of the payment authorization request 
the TA will validate the client and the merchant using the information provided. 
The TA then generates a validation request to the client that includes the unique 
transaction identifier. This communication between the TA and the client may be 
encrypted using a suitable encryption method or a set of virtual keys known only 
to the TA and each individual purchaser. 
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— Upon receipt of the validation request, the client decodes, if 
necessary, the encrypted validation request and extracts the unique transaction 
identifier therefrom. The identifier is compared to a listing of generated 
transaction identifiers at the client to confirm that the client authorized the 
transaction order with which the transaction identifier is associated. Confirmation 
or denial of the validation is transmitted back to the TA by the originator This 
confirmation may be encrypted using a suitable encryption method, if necessary.. 
To provide additional security, a query or group of queries may be included within 
the validation requests between the TA and the originator These queries are 
randomly generated and directed to information known solely by the originator, 
such as mother's maiden name, social security number, driver's license number, 
birth date, etc. 

— Upon receipt of validation or non-validation from the originator, the 
TA confirms or aborts the transaction by notifying the recipient whether or not the 
transaction is valid based upon the originator's validation response and the 
accuracy of the information contained in the transaction request If the 
information in the transaction request checks out, the item(s) ordered may be 
delivered to the originator by the recipient The delivery and communication 
systems between the client, merchant and TA preferably consists of some type of 
computer network such as the Internet, private Intranet or any suitable network. 
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a present status of processing for delivery of said product corresponding 
to said order, as disclosed by the functionality of Talati in: 

— (col. 1 lines 55-67) The delivery system between the client 10 and 
the merchant 20 can be a regular mail system, telephone system, computer 
network or any other delivery system like UPS or Federal Express. The delivery 
system between the client 10 and the merchant 20 must also have some tracking 
capability. The delivery system between the merchant 20 and the CCA 30 is 
typically a private network providing Point-Of-Sale (POS) processing. All 
necessary information is transferred between two or more points in this network 
with a tracking mechanism that can follow the transactions. All of the above 
steps can also be executed within electronic commerce transactions; 

— (col. 6 lines 33-43) The CA 60 responds at step 180, with an 
authorization for the transaction if the client 50 transaction and credit limit have 
been approved by the CA processor 61 and if there is a confirmation by client 10 
of transaction validity. If the transaction is not validated by either the CA 60 or 
client 50, the CA transmits a rejection of the requested transaction to the 
merchant at step 185, and the client is notified by the merchant of the rejection at 
step 190. Upon confirmation of the purchase order, the merchandise may be 
delivered to the client 50 and a credit card transaction can be completed between 
client 50 and merchant 55 at step 195. 

— (col. 1 1 lines 38-51 ) there is illustrated an exchange of information 
between an originator 50 and a recipient 55 using an e-mail delivery system 305. 
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Information is synonymous with document, software, classified data, transaction 
data or a database query and responses. The invention provides a method to 
securely exchange and process information between originator 50 and recipient 
55, where an originator and recipient can be client or server on the 
Internet/Intranet or private network. 

— (col. 1 1 lines 51-65) While the following is described with respect 
to an e-mail delivery system it should be realized that any type of delivery system 
would be useful. The originator 50 sends a document including a UTID and 
originator identifier (OID) to recipient 55 within an e-mail message at 430. Upon 
receipt of the e-mail message, the recipient 55 forwards another e-mail message 
to the transaction administrator (TA) 60 at 435. The e-mail message includes the 
OID, UTID and document name. The TA 60 authenticates the OID of originator 
so a message can be transmitted to the originator. If OID does not authorize, the 
TA 60 sends a negative response to recipient 55 at 450. Otherwise, the TA 60 
requests originator 50 to validate the transaction via another e-mail message at 
440. The e-mail message includes the UTID. 

(col. 1 1 line 66 - col. 12 line 8) The originator 50 validates 
transactions by comparing UTID with a list 100, including UTIDs generated by 
the originator along with associated information. The originator 50 sends a 
negative acknowledgment due to failure to match a UTID or associated 
information if the transaction is invalid or a positive acknowledgment if the 
transaction is valid and the UTID and associated information matches at 445. 
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The TA 60 upon receipt of a positive or negative validation of the transaction with 
the associated UTID notifies the recipient of a positive status at 450.\ 

(col. 1 2 line 9-1 9) The originator and the recipient then completes 
the information transaction at 455. For example, if recipient receives a positive 
acknowledgment for transaction, it accepts the information. Since the OID is 
authenticated by the TA 60, the recipient 55 is guaranteed that the information is 
received from the desired originator. In this example, since the originator 50 has 
validated the transaction and information, the originator is guaranteed that 
recipient 55 has received the information. The transaction administrator 60 may 
be any entity, such as a Government authority, U.S. Post Office, etc. 

a present status of processing for payment processing for said trading, as 
disclosed by the functionality of Talati in: 

(col. 6 lines 1-24) Upon receipt of the payment authorization 
request from the merchant 55, a CA processor 61 determines if the purchase 
order is authorized at step 100 by attending to the validity of the credit card 
number, merchant, amount of purchase, etc., and determine the client identity. 
The CA 60 transmits at step 165, the purchase order and the associated UTID 60 
and purchase order data to the client processor 70. The UTID 60 and purchase 
order data are processed at the client 50 to determine if they are valid. The 
transmission from the CA 60 to the client 50 may be encoded using some type of 
virtual encryption key or any suitable encryption technology. The client 
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processor 70 decodes the transmission (if encrypted) using knowledge of the 
virtual encryption key method between the client 50 and the CA 60 and 
compares the received unique transaction identifier to a unique transaction 
identifier list 100 of identifiers transmitted from the client at step 170 to determine 
whether to validate the transaction. The results of the validation is then 
forwarded to the CA 60. If the UTID 60 matches an entry within the client list 100 
and the purchase order data checks out with what the client 50 expects, the 
requested transaction is identified as valid. If no match for the UTID is found or if 
the purchase order data is incorrect the requested transaction is identified as 
invalid or fraudulent 

(col. 6 lines 33-43) The CA 60 responds at step 180, with an 
authorization for the transaction if the client 50 transaction and credit limit have 
been approved by the CA processor 61 and if there is a confirmation by client 10 
of transaction validity. If the transaction is not validated by either the CA 60 or 
client 50, the CA transmits a rejection of the requested transaction to the 
merchant at step 185, and the client is notified by the merchant of the rejection at 
step 190. Upon confirmation of the purchase order, the merchandise may be 
delivered to the client 50 and a credit card transaction can be completed between 
client 50 and merchant 55 at step 195. 

(col. 6 lines 1-24; col. 7 lines 25-63): 

Upon receipt of the payment authorization request from the 
merchant 55, a CA processor 61 determines if the purchase order is authorized 
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at step 100 by attending to the validity of the credit card number, merchant, 
amount of purchase, etc., and determine the client identity. The CA 60 transmits 
at step 165, the purchase order and the associated UTID 60 and purchase order 
data to the client processor 70. The UTID 60 and purchase order data are 
processed at the client 50 to determine if they are valid. The transmission from 
the CA 60 to the client 50 may be encoded using some type of virtual encryption 
key or any suitable encryption technology. The client processor 70 decodes the 
transmission (if encrypted) using knowledge of the virtual encryption key method 
between the client 50 and the CA 60 and compares the received unique 
transaction identifier to a unique transaction identifier list 100 of identifiers 
transmitted from the client at step 1 70 to determine whether to validate the 
transaction. The results of the validation is then forwarded to the CA 60. If the 
UTID 60 matches an entry within the client list 100 and the purchase order data 
checks out with what the client 50 expects, the requested transaction is identified 
as valid. If no match for the UTID is found or if the purchase order data is 
incorrect the requested transaction is identified as invalid or fraudulent. 

The CA 60 responds at step 180, with an authorization for the 
transaction if the client 50 transaction and credit limit have been approved by the 
CA processor 61 and if there is a confirmation by client 10 of transaction validity. 
If the transaction is not validated by either the CA 60 or client 50, the CA 
transmits a rejection of the requested transaction to the merchant at step 185, 
and the client is notified by the merchant of the rejection at step 190. Upon 
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confirmation of the purchase order, the merchandise may be delivered to the 
client 50 and a credit card transaction can be completed between client 50 and 
merchant 55 at step 195. 

— (see col. 9 lines 32-44) In the case of an electronic check 
transaction, the mail contents 348 of the e-mail may comprise a number of items, 
depending on who the e-mail is from, and the data required to be extracted by 
the e-mail control system 300 of the receiving party. A transaction request from 
the originator 50 may include an account number, amount of the transaction, 
account reference, transaction reference, and originator's personal information. 
A response from a recipient 55 may include account number information, account 
references, transaction references, and recipient's personal information. An e- 
mail message from the transaction administrator 60 may contain query 
information for the originator to obtain validation. 

the trading identifier (col. 3 lines 4-19; col. 6 lines 1-32; col. 7 lines 25-63); 

and 

comparing said trading identifier and said e-mail address included in said trading 
information with said trading identifier included in said trading processing information, as 
disclosed by Talati in the disclosure: 

(col. 3 lines 20-48) The identifier is compared to a listing of generated 
transaction identifiers at the client to confirm that the client authorized the 
transaction order with which the transaction identifier is associated. 
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(col. 2 lines 51-55) The present invention overcomes the foregoing and 
other problems with a method and apparatus enabling verification and validation 
of original "electronic commerce transactions" between one or more originators, 
recipients, and transaction administrators (TA). 

(col. 4 lines 52-6) The transaction request includes a unique transaction 
identifier (UTID) associated with the specific transaction request and originator 
identity (OID) to identify the originator 50 to a transaction administrator 60 

(col. 4 line 66 - col. 5 line 32) 

— Recipient 55 first reviews the transaction request using a processor 
75 and generates a request for authentication of the originator 50 using the OID, 
UTID and the information content of the transaction request such as an amount 
or document name at step 80 to the transaction administrator. The transaction 
administrator 60 first validates the identity of recipient 55 and then the OID at 
step 85. If the OID is invalid, the transaction administrator 60 notifies the 
recipient 55 of the invalidity and the transaction is denied. If the OID is valid, the 
transaction administrator 60 determines the originator associated with the OID, 
transmits the transaction request and associated data to the originator 50 and 
requests that the originator validate the transaction request containing the UTID 
at step 90. The transaction administrator 60 may also validate transaction 
amounts and credit limits at this time or upon receiving a response for the 
originator 50. 
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— The originator 50 validates the transaction by comparing at step 95 
the UTID with a list 100 generated by the processor 70 of the originator listing the 
UTID associated with each transaction generated by the originator and notifying 
the transaction administrator 60 of the results. The list 100 also includes the 
details of the transaction (amount; parties, etc.) associated with the UTID which 
must also be validated by the originator 50. The transaction is granted or 
rejected by the transaction administrator 60 based on the comparison results at 
step 105. If the originator 50 does not validate the transaction at step 95, the 
transaction administrator 60 rejects the transaction at step 110 which invalidates 
the transaction. The originator is notified at step 115 of the invalidation of the 
transaction. Upon receipt of the transaction validation status from the originator 
50, the transaction administrator 60 validates the originator 50 and the 
transaction request at step 120, and notifies the recipient 55. The originator 50 
and recipient 55 then complete the transaction at step 125. 

(col. 11 line 51 - col. 12 line 8): 

While the following is described with respect to an e-mail delivery 
system it should be realized that any type of delivery system would be useful. 
The originator 50 sends a document including a UTID and originator identifier 
(01 D) to recipient 55 within an e-mail message at 430. Upon receipt of the e-mail 
message, the recipient 55 forwards another e-mail message to the transaction 
administrator (TA) 60 at 435. The e-mail message includes the 01 D, UTID and 
document name. The TA 60 authenticates the 01 D of originator so a message 
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can be transmitted to the originator. If OID does not authorize, the TA 60 sends 
a negative response to recipient 55 at 450. Otherwise, the TA 60 requests 
originator 50 to validate the transaction via another e-mail message at 440. The 
e-mail message includes the UTID. 

The originator 50 validates transactions by comparing UTID with a 
list 100, including UTIDs generated by the originator along with associated 
information. The originator 50 sends a negative acknowledgment due to failure to 
match a UTID or associated information if the transaction is invalid or a positive 
acknowledgment if the transaction is valid and the UTID and associated 
information matches at 445. The TA 60 upon receipt of a positive or negative 
validation of the transaction with the associated UTID notifies the recipient of a 
positive status at 450. 

Talati does not specifically disclose adding said trading processing information to 
said trading information stored in said storage device if they are coincident. Official 
Notice is taken that it was old and well known that data could be added to a database or 
modified in a database as necessary or desired by the user. Also, Wiecha discloses: 

adding, deleting and editing trading processing information to trading information 
stored in said storage device (col. 9 lines 1-11); and 

Purchaser can update status of PO manually after receiving acknowledgements, 
status updates, etc. from vendors via fax, phone, or mail. Changes to the PO can then 
be saved to the DB2/2 database on the Purchasing Server (col. 9 lines 59-63). 
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Therefore, it would have been obvious to one skilled in the art at the time the 
invention was made to modify Talati to disclose a present status of processing for 
processing initiated for said order, and adding said trading processing information to 
said trading information stored in said storage device if they are coincident, as disclosed 
by Wiecha and old and well known art, because this could provide useful and desirable 
information to users who track their transactions and provide additional functionality to 
the database. 

Claim 2: Talati discloses comparing said data on the contents of said order 
included in said trading information with: 

said present status of processing (col. 2 lines 51-55; col. 4 lines 66-67; col. 5 
lines 1-67; col. 6 lines 1-43), as disclosed through the functionality of Talati in the 
disclosures: 

- (col. 2 lines 51-55) The present invention overcomes the foregoing and other 
problems with a method and apparatus enabling verification and validation of original 
"electronic commerce transactions" between one or more originators , recipients, and 
transaction administrators (TA). 

- (col. 3 lines 34-39) Upon receipt of the validation request the client decodes, if 
necessary, the encrypted validation request and extracts the unique transaction 
identifier therefrom. The identifier is compared to a listing of generated transaction 
identifiers at the client to confirm that the client authorized the transaction order with 
which the transaction identifier is associated. 
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- (col. 5 lines 1 5-1 9) The originator 50 validates the transaction by comparing at 
step 95 the UTID with a list 100 generated by the processor 70 of the originator 
listing the UTID associated with each transaction generated by the originator and 
notifying the transaction administrator 60 of the results. 

- (col. 6 lines 1 2-18) The client processor 70 decodes the transmission (if 
encrypted) using knowledge of the virtual encryption key method between the client 
50 and the CA 60 and compares the received unique transaction identifier to a 
unique transaction identifier list 100 of identifiers transmitted from the client at step 
170 to determine whether to validate the transaction. 

said present status of processing for delivery (col. 2 lines 51-55; col. 4 lines 66- 
67; col. 5 lines 1-67; col. 6 lines 1-43), as disclosed through the functionality of Talati in 
the disclosures: 

-- (col. 6 lines 1 2-18) The client processor 70 decodes the transmission (if 
encrypted) using knowledge of the virtual encryption key method between the client 
50 and the CA 60 and compares the received unique transaction identifier to a 
unique transaction identifier list 100 of identifiers transmitted from the client at step 
170 to determine whether to validate the transaction. 
; and 

said present status of processing for the payment processing (col. 2 lines 51-55; 
col. 4 lines 66-67; col. 5 lines 1-67; col. 6 lines 1-43); and 
outputting a warning message (col. 3 lines 49-54). 
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Claim 3: Talati discloses: 

sending to said server a transmission request for trading processing information 
including the trading identifier (col. 3 lines 3-19). 

Claim 4: Talati discloses transmitting: 

a time at which said trading processing information is to be received (col. 10 lines 
16-29); and 

a request for said processing information (col. 10 lines 16-29). 

Claim 5: Talati does not specifically disclose said present status of processing 
includes a delivery completed date for the product; a scheduled delivery date for said 
product; nor a payment completed date or scheduled payment date. Official Notice is 
taken that a present status of processing for purchase and delivery of products 
purchased by buyers is normally provided upon request of the buyer and may include 
any or all of: a delivery completed date for the product; a scheduled delivery date for 
said product; and a payment completed date or scheduled payment date. Buyers 
typically request the present status of their orders and when delivery will be completed. 
Therefore, it would have been obvious to one skilled in the art at the time the invention 
was made to modify Talati to disclose said present status of processing includes a 
delivery completed date for the product; a scheduled delivery date for said product; nor 
a payment completed date or scheduled payment date, as disclosed by Wiecha with old 
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and well known art, because this provides information that sellers and buyers typically 
want pertaining to purchases. 

Claim 6: Neither Talati nor Wiecha specifically discloses displaying trading for 
which delivery has been completed separately from trading for which delivery has not 
been completed; nor displaying trading which have been settled separately from trading 
which have not been settled. However, Official Notice is taken that it was old and well 
known in the art at the time the invention was made that information in a database may 
be displayed as required or desired by a buyer or user. Information in a database may 
be manipulated as desired by the database user. Therefore, it would have been 
obvious to one skilled in the art at the time the invention was made to modify Talati and 
Wiecha to disclose displaying trading for which delivery has been completed separately 
from trading for which delivery has not been completed, and displaying trading which 
have been settled separately from trading which have not been settled, as disclosed by 
old and well known art, because this provides information that seller and buyers want 
pertaining to purchases. 

Claim 7: Neither Talati nor Wiecha specifically discloses calculating a total amount 
of money for products which have not been settled; nor displaying the calculated total 
amount of money. However, Official Notice is taken that calculating a total amount of 
money for products which have not been settled and displaying the calculated total 
amount of money was old and well known in the art at the time the invention was made. 
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These are typical functions associated with merchant billing practices in merchant 
locations and at Internet merchant sites, including informing a buyer of the amount for 
items/products that he currently is ordering. Therefore, it would have been obvious to 
one skilled in the art at the time the invention was made to modify the disclosures of 
Talati and Wiecha to disclose calculating a total amount of money for products which 
have not been settled, and displaying the calculated total amount of money, as 
disclosed by old and well known art with, because this supports seller functions for 
making sales and informs buyers of the amount/value for their proposed purchases. 

Claim 8: Talati discloses: 

comparing said total amount of money with a predetermined limit amount (col. 5 
lines 12-14); and 

outputting a warning if said total amount of money for the products which have 
not been settled exceeds aid limit amount (col. 5 lines 15-33). 

Claim 9: Neither Talati nor Wiecha specifically discloses inputting information on a 
product to be returned nor transmitting said information to said server. Official Notice is 
taken that inputting information and transmitting information were old and well known in 
the art at the time the invention was made. Additionally, Talati discloses transmitting 
information by a client in connection with a transaction. Also, Official Notice is taken 
that it would have been obvious to one skilled in the art at the time the transaction was 
made to provide a capability for the return of defective or unwanted merchandise as this 
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is a common problem in most merchandising systems and retail systems. Typically, 
merchants provide a means to accommodate buyers who want to return defective or 
unwanted merchandise in order to maintain customer satisfaction. Therefore, it would 
have been obvious to one skilled in the art at the time the invention was made to modify 
Talati and Wiecha to disclose inputting information on a product to be returned and 
transmitting said information to said server, as disclosed by old and well known art, 
because this provides desired customer service functions to the system. 

Claim 1 0: Neither Talati nor Wiecha specifically disclose displaying said trading 
information to select a portion of information; creating new order information by 
modifying said selected information; nor transmitting said new order information to said 
server. However, Official Notice is taken that it was old and well known in the art at the 
time the invention was made that computer systems included operating system software 
that facilitated cut and paste operations with data to copy or transfer data between 
applications and /or files or documents. Additionally, Official Notice is taken that it was 
old and well known in the art at the time the invention was made that users could create 
new documents by editing old files/documents, making changes, and saving the revised 
file/document as a new file, such as a new order. It would have been obvious to one 
skilled in the art at the time the invention was made to modify with Talati and Wiecha to 
disclose displaying said trading information to select a portion of information; creating 
new order information by modifying said selected information; and transmitting said new 
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order information to said server, as disclosed by old and well known art, because this 
facilitates users generating new orders from stored files of previous orders. 

Claim 1 1 : Talati discfoses: 
said server includes: 

a shopping server (col. 4 lines 63-65); 
a payment managing server (col. 4 lines 63-65); and 
a delivery managing server (col. 4 lines 63-65); 
receiving said present status of processing for the processing for said order from 
said shopping server (col. 6 lines 1-24); 

receiving said present status of processing for said payment processing for 
trading from said payment managing server (col. 6 lines 1-43); 

receiving said present status of processing for the processing for said delivery 
from said delivery managing server (col. 6 lines 1-60); 

Claim 12: Talati discloses sending to said shopping server a transmission request 
for order processing information including a trading identifier (col. 6 lines 1-60). 
Claim 13: Talati discloses sending to said payment managing server a transmission 
request for payment managing processing information including the trading identifier 
(col. 6 lines 1-60). 
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Claim 14: Talati discloses sending to said delivery managing server a transmission 
request for delivery managing processing information including the trading identifier (col. 
6 lines 1-60). 

Claim 29: Talati discloses repeating: 

said step of receiving trading processing information (col. 3 lines 20-48); and 
said step of comparing (col. 3 lines 20-48). 

Claim 30: Talati discloses: 

receiving an order for a product in response to an input by a user through a 
communication network (col. 3 lines 4-33); 

performing order acceptance processing for said product (col. 3 lines 20-33); 

transmitting to said client trading information including a trading identifier and 
data on the contents of said order (col. 3 lines 20-33); 

storing said trading information and an e-mail address (col. 8 lines 62-67; col. 9 
lines 1-11; fig. 12 [331, 335, 340); 

creating trading processing information including: 

a present status of processing for processing initiated for said order, as 
disclosed by Talati through the functionality of: 

(col. 1 1 lines 38-51 ) there is illustrated an exchange of information 

between an originator 50 and a recipient 55 using an e-mail delivery system 305. 

Information is synonymous with document, software, classified data, transaction 
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data or a database query and responses. The invention provides a method to 
securely exchange and process information between originator 50 and recipient 
55, where an originator and recipient can be client or server on the 
Internet/Intranet or private network. 

(col. 1 1 lines 51-65) While the following is described with respect 
to an e-mail delivery system it should be realized that any type of delivery system 
would be useful. The originator 50 sends a document including a UTID and 
originator identifier (OID) to recipient 55 within an e-mail message at 430. Upon 
receipt of the e-mail message, the recipient 55 forwards another e-mail message 
to the transaction administrator (TA) 60 at 435. The e-mail message includes the 
OID, UTID and document name. The TA 60 authenticates the OID of originator 
so a message can be transmitted to the originator. If OID does not authorize, the 
TA 60 sends a negative response to recipient 55 at 450. Otherwise, the TA60 
requests originator 50 to validate the transaction via another e-mail message at 
440. The e-mail message includes the UTID. 

(col. 1 1 line 66 - col. 12 line 8) The originator 50 validates 
transactions by comparing UTID with a list 100, including UTIDs generated by 
the originator along with associated information. The originator 50 sends a 
negative acknowledgment due to failure to match a UTID or associated 
information if the transaction is invalid or a positive acknowledgment if the 
transaction is valid and the UTID and associated information matches at 445. 
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The TA 60 upon receipt of a positive or negative validation of the transaction with 
the associated UTID notifies the recipient of a positive status at 450. 

(col. 5 line 50 - col. 6 line 60) verifying and validating various steps 
of transactions; 

— (col. 8 line 62 -- col. 9 line 1 1 ) A format of an e-mail record 330 is 
more fully described in FIG. 12 wherein there is shown an e-mail record 330 
including the unique transaction identifier or message id 331; a mail type 
identification 335 indicating whether the record is to be transmitted, was just 
received, has already been transmitted, or comprise a transaction e-mail; the 
recipient's address 340; the subject matter of the e-mail 345; and the contents of 
the e-mail 348. For simplicity, the mail type identification 335 identifies the state 
of the e-mail record as it relates to the state of the e-mail delivery system 305. 
For example, when a user creates an e-mail record, the ECS 300 deposits this 
e-mail record into the mailbox database 315 with mail "type" equal to 1 indicating 
that the e-mail record is ready to be delivered to the recipients. The recipient 
address 340, subject matter 345 and contents 348 provide routing and content 
information to the e-mail delivery system 305. 

(col. 3 lines 4-59): 

— A validated transaction is a transaction in which the TA validates 
the entities, facilitates the transaction and/or validates the contents of the 
transaction by the originator. In a validated electronic commerce transaction, 
either the client, merchant or transaction administrator can initiate the 
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transaction. In a purchase transaction, the client initiates a transaction 
requesting particular items of merchandise or services from a merchant via the 
Internet a dial-up-network, or any suitable network. The electronic transaction 
includes details of the transaction such as descriptions of the item(s) that the 
client desires to purchase, credit card or check payment information, information 
on other types of payment by means of which the item(s) will be purchased, and 
a unique transaction identifier that has been generated by the originator and is 
uniquely associated with the particular purchase transaction. 

— This information is transmitted to the merchant over the network. In 
response to the purchase order, the merchant generates a payment authorization 
request for transmission to the TA. The payment authorization request will have 
attached to it the unique transaction identifier initially provided by the client along 
with transaction information. Upon receipt of the payment authorization request 
the TA will validate the client and the merchant using the information provided. 
The TA then generates a validation request to the client that includes the unique 
transaction identifier. This communication between the TA and the client may be 
encrypted using a suitable encryption method or a set of virtual keys known only 
to the TA and each individual purchaser. 

— Upon receipt of the validation request, the client decodes, if 
necessary, the encrypted validation request and extracts the unique transaction 
identifier therefrom. The identifier is compared to a listing of generated 
transaction identifiers at the client to confirm that the client authorized the 
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transaction order with which the transaction identifier is associated. Confirmation 
or denial of the validation is transmitted back to the TA by the originator. This 
confirmation may be encrypted using a suitable encryption method, if necessary. 
To provide additional security, a query or group of queries may be included within 
the validation requests between the TA and the originator. These queries are 
randomly generated and directed to information known solely by the originator, 
such as mother's maiden name, social security number, driver's license number, 
birth date, etc. 

— Upon receipt of validation or non-validation from the originator, the 
TA confirms or aborts the transaction by notifying the recipient whether or not the 
transaction is valid based upon the originator's validation response and the 
accuracy of the information contained in the transaction request. If the 
information in the transaction request checks out, the item(s) ordered may be 
delivered to the originator by the recipient. The delivery and communication 
systems between the client, merchant and TA preferably consists of some type of 
computer network such as the Internet, private Intranet or any suitable network. 



a present status of processing for delivery of said product corresponding 
to said order, as disclosed by the functionality of Talati in: 

— (col. 1 lines 55-67) The delivery system between the client 10 and 
the merchant 20 can be a regular mail system, telephone system, computer 
network or any other delivery system like UPS or Federal Express. The delivery 
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system between the client 10 and the merchant 20 must also have some tracking 
capability. The delivery system between the merchant 20 and the CCA 30 is 
typically a private network providing Point-Of-Sale (POS) processing. All 
necessary information is transferred between two or more points in this network 
with a tracking mechanism that can follow the transactions. All of the above 
steps can also be executed within electronic commerce transactions; 



authorization for the transaction if the client 50 transaction and credit limit have 
been approved by the CA processor 61 and if there is a confirmation by client 10 
of transaction validity. If the transaction is not validated by either the CA 60 or 
client 50, the CA transmits a rejection of the requested transaction to the 
merchant at step 185, and the client is notified by the merchant of the rejection at 
step 190. Upon confirmation of the purchase order, the merchandise may be 
delivered to the client 50 and a credit card transaction can be completed between 
client 50 and merchant 55 at step 195. 



between an originator 50 and a recipient 55 using an e-mail delivery system 305. 
Information is synonymous with document, software, classified data, transaction 
data or a database query and responses. The invention provides a method to 
securely exchange and process information between originator 50 and recipient 
55, where an originator and recipient can be client or server on the 
Internet/Intranet or private network. 



(col. 6 lines 33-43) The CA 60 responds at step 180, with an 



(col. 1 1 lines 38-51) there is illustrated an exchange of information 
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— (col 1 1 lines 51-65) While the following is described with respect 
to an e-mail delivery system it should be realized that any type of delivery system 
would be useful. The originator 50 sends a document including a UTID and 
originator identifier (OID) to recipient 55 within an e-mail message at 430. Upon 
receipt of the e-mail message, the recipient 55 forwards another e-mail message 
to the transaction administrator (TA) 60 at 435. The e-mail message includes the 
OID, UTID and document name. The TA 60 authenticates the OID of originator 
so a message can be transmitted to the originator. If OID does not authorize, the 
TA 60 sends a negative response to recipient 55 at 450. Otherwise, the TA 60 
requests originator 50 to validate the transaction via another e-mail message at 
440. The e-mail message includes the UTID. 



transactions by comparing UTID with a list 100, including UTIDs generated by 
the originator along with associated information. The originator 50 sends a 
negative acknowledgment due to failure to match a UTID or associated 
information if the transaction is invalid or a positive acknowledgment if the 
transaction is valid and the UTID and associated information matches at 445. 
The TA 60 upon receipt of a positive or negative validation of the transaction with 
the associated UTID notifies the recipient of a positive status at 450A 



the information transaction at 455. For example, if recipient receives a positive 
acknowledgment for transaction, it accepts the information. Since the OID is 



(col. 1 1 line 66 - col. 12 line 8) The originator 50 validates 



(col. 12 line 9-19) The originator and the recipient then completes 
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authenticated by the TA 60, the recipient 55 is guaranteed that the information is 
received from the desired originator In this example, since the originator 50 has 
validated the transaction and information, the originator is guaranteed that 
recipient 55 has received the information. The transaction administrator 60 may 
be any entity, such as a Government authority, U.S. Post Office, etc. 

a present status of processing for payment processing for said trading, as 
disclosed by the functionality of Talati in: 



request from the merchant 55, a CA processor 61 determines if the purchase 
order is authorized at step 1 00 by attending to the validity of the credit card 
number, merchant, amount of purchase, etc., and determine the client identity. 
The CA 60 transmits at step 165, the purchase order and the associated UTID 60 
and purchase order data to the client processor 70. The UTID 60 and purchase 
order data are processed at the client 50 to determine if they are valid. The 
transmission from the CA 60 to the client 50 may be encoded using some type of 
virtual encryption key or any suitable encryption technology. The client 
processor 70 decodes the transmission (if encrypted) using knowledge of the 
virtual encryption key method between the client 50 and the CA 60 and 
compares the received unique transaction identifier to a unique transaction 
identifier list 100 of identifiers transmitted from the client at step 170 to determine 
whether to validate the transaction. The results of the validation is then 



(col. 6 lines 1-24) Upon receipt of the payment authorization 
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forwarded to the CA 60. If the UTID 60 matches an entry within the client list 100 
and the purchase order data checks out with what the client 50 expects, the 
requested transaction is identified as valid. If no match for the UTID is found or if 
the purchase order data is incorrect the requested transaction is identified as 
invalid or fraudulent. 



authorization for the transaction if the client 50 transaction and credit limit have 
been approved by the CA processor 61 and if there is a confirmation by client 10 
of transaction validity. If the transaction is not validated by either the CA 60 or 
client 50, the CA transmits a rejection of the requested transaction to the 
merchant at step 185, and the client is notified by the merchant of the rejection at 
step 190. Upon confirmation of the purchase order, the merchandise maybe 
delivered to the client 50 and a credit card transaction can be completed between 
client 50 and merchant 55 at step 195. 



merchant 55, a CA processor 61 determines if the purchase order is authorized 
at step 100 by attending to the validity of the credit card number, merchant, 
amount of purchase, etc., and determine the client identity. The CA 60 transmits 
at step 165, the purchase order and the associated UTID 60 and purchase order 
data to the client processor 70. The UTID 60 and purchase order data are 
processed at the client 50 to determine if they are valid. The transmission from 



(col. 6 lines 33-43) The CA 60 responds at step 180, with an 



(col. 6 lines 1-24; col. 7 lines 25-63): 



Upon receipt of the payment authorization request from the 
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the CA 60 to the client 50 may be encoded using some type of virtual encryption 
key or any suitable encryption technology. The client processor 70 decodes the 
transmission (if encrypted) using knowledge of the virtual encryption key method 
between the client 50 and the CA 60 and compares the received unique 
transaction identifier to a unique transaction identifier list 100 of identifiers 
transmitted from the client at step 170 to determine whether to validate the 
transaction. The results of the validation is then forwarded to the CA 60. If the 
UTID 60 matches an entry within the client list 100 and the purchase order data 
checks out with what the client 50 expects, the requested transaction is identified 
as valid. If no match for the UTID is found or if the purchase order data is 
incorrect the requested transaction is identified as invalid or fraudulent 



transaction if the client 50 transaction and credit limit have been approved by the 
CA processor 61 and if there is a confirmation by client 10 of transaction validity. 
If the transaction is not validated by either the CA 60 or client 50, the CA 
transmits a rejection of the requested transaction to the merchant at step 185, 
and the client is notified by the merchant of the rejection at step 190. Upon 
confirmation of the purchase order, the merchandise may be delivered to the 
client 50 and a credit card transaction can be completed between client 50 and 
merchant 55 at step 195. 

(see col. 9 lines 32-44) In the case of an electronic check 
transaction, the mail contents 348 of the e-mail may comprise a number of items, 



The CA 60 responds at step 180, with an authorization for the 




Application/Control Number: 08/979,810 



Page 34 



Art Unit: 3625 

depending on who the e-mail is from, and the data required to be extracted by 
the e-mail control system 300 of the receiving party. A transaction request from 
the originator 50 may include an account number, amount of the transaction, 
account reference, transaction reference, and originator's personal information. 
A response from a recipient 55 may include account number information, account 
references, transaction references, and recipient's personal information. An e- 
mail message from the transaction administrator 60 may contain query 
information for the originator to obtain validation. 



col. 8 lines 29-33); and 

obtaining an e-mail address of a client (col. 8 lines 62-67; col. 9 lines 1-11); and 
transmitting said trading processing information to said client (col. 3 lines 20-33). 

Talati does not explicitly disclose managing the present status of processing until 
the order processing, the delivery and the payment processing are completed. Talati 
does disclose verifying and validating various steps of transactions (col. 5 lines 50-67; 
col. 6 lines 1-60). Official Notice is taken that it was old and well known that data could 
be added to a database or modified in a database as necessary or desired by the user. 
Additionally, Wiecha discloses Purchaser can update status ofPO manually after 
receiving acknowledgements, status updates, etc. from vendors via fax, phone, or mail. 
Changes to the PO can then be saved to the DB2/2 database on the Purchasing Server 
(col. 9 lines 59-63). Therefore, it would have been obvious to one skilled in the art at 



the trading identifier (col. 3 lines 4-19; col. 6 lines 1-32; col. 7 lines 25-63; 



• # 
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the time the invention was made to modify Talati to disclose managing the present 
status of processing until the order processing, the delivery and the payment processing 
are completed, as disclosed by Wiecha, because this provides functionality that users 
desire in reviewing and managing their requested processing (i.e., purchases). 



Claim 31 : Talati discloses repeating until an end of said trading: 

creating said trading processing information (col. 11 lines 38-67; col. 12 lines 1- 

19; col. 6 lines 25-43; col. 6 lines 1-32); 

obtaining said e-mail address (col. 8 lines 62-67; col. 9 lines 1-11); and 
transmitting said trading processing information until an end of said trading (col. 3 

lines 20-33). 

Claim 32: Talati discloses: 

based on a trading identifier, searching for the present status of processing to 
create trading processing information (col. 10 lines 41-67; col. 11 lines 37); and 

transmitting said trading processing information to said client (col. 3 lines 20-33). 

Claim 33: Claim 33 is written as a server and contains the same limitations as claim 
30; therefore, the same rejection is applied. 

Claim 34: Claim 34 is written as a storage medium and contains the same limitations 
as claim 32; therefore, the same rejection is applied. 
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Claim 35: Claim 35 is written as a server and contains the same limitations as claim 
30; therefore, the same rejection is applied. 

Claim 37: Claim 37 is written as a server and contains the same limitations as claim 
30; therefore, the same rejection is applied. 

Claim 38: Claim 38 is written as a client and contains the same limitations as claim 
2; therefore, the same rejection is applied. 

Claim 39: Claim 39 is written as a client and contains the same limitations as claim 
3; therefore, the same rejection is applied. 

Claim 40: Claim 40 is written as a client and contains the same limitations as claim 
4; therefore, the same rejection is applied. 

Claim 41 : Claim 41 is written as a client and contains the same limitations as claim 
1 1 ; therefore, the same rejection is applied. 

Claim 42: Neither Talati nor Wiecha disclose a reordering device. Talati does 
disclose storing said trading information and an e-mail address (col. 8 lines 62-67; col. 9 
lines 1-11; fig. 12 [331, 335, 340). Official notice is taken that it was old and well known 
in the art at the time the invention was made that data in a database could be used 
more than once (i.e., reused) in output reports (e.g., purchase orders) generated from 
the database, and that reports could be generated using the same data (duplicated) or a 
combination of the same data and additional data from the database. This is one 
reason that databases are used. Also, Official Notice is taken that it was old and well 



• 



Application/Control Number: 08/979,810 
Art Unit: 3625 



Page 37 



known in the art at the time the invention was made that many businesses generate and 
process orders for goods and services that are repeated over time. Businesses 
maintain stock levels in their inventory, and re-order periodically to replenish depleted 
stock levels or replace exhausted stock or renew performance agreements. It would 
have been obvious to one skilled in the art at the time the invention was made to modify 
the disclosures of Talati and Wiecha to disclose a reordering device, as disclosed in old 
and well known art, because businesses must maintain stock levels or renew 
performance agreements in order to stay in business, and reordering goods based on 
prior orders in combination with goods usage (or sales) simplifies the reorder process. 

Claim 43: Claim 43 is written as a server and contains the same limitations as claim 
30; therefore, the same rejection is applied. 

Claim 44: Claim 44 is written as a client and contains the same limitations as claim 
2; therefore, the same rejection is applied. 

7. Claim 36 is rejected in Paper #29 under 35 U.S.C. 103(a) as being unpatentable 
over Talati et al. (U.S. Patent No. 5,903,878) hereafter referred to as Talati, and further 
in view of Wiecha (U.S. Patent No. 5,870,717). 



Claim 36: Talati discloses a storage medium comprising storage components having 
a code sequence for: 



Application/Control Number: 08/979,810 Page 38 

Art Unit: 3625 

receiving an order (col. 1 1 lines 60-67; col. 12 lines 1-19); 
performing order acceptance processing (col. 1 1 lines 60-67; col. 12 lines 1-19); 
transmitting to said client trading information (col. 3 lines 20-33); 
transmitting to said client a present status of processing (col. 1 1 lines 60-67; col. 
12 lines 1-19), as disclosed by Talati through the functionality of: 

— there is illustrated an exchange of information between an 
originator 50 and a recipient 55 using an e-mail delivery system 305. Information 
is synonymous with document, software, classified data, transaction data or a 
database query and responses. The invention provides a method to securely 
exchange and process information between originator 50 and recipient 55, where 
an originator and recipient can be client or server on the Internet/Intranet or 
private network. 

While the following is described with respect to an e-mail delivery 
system it should be realized that any type of delivery system would be useful. 
The originator 50 sends a document including a UTID and originator identifier 
(OID) to recipient 55 within an e-mail message at 430. Upon receipt of the e-mail 
message, the recipient 55 forwards another e-mail message to the transaction 
administrator (TA) 60 at 435. The e-mail message includes the OID, UTID and 
document name. The TA 60 authenticates the OID of originator so a message 
can be transmitted to the originator. If OID does not authorize, the TA 60 sends 
a negative response to recipient 55 at 450. Otherwise, the TA 60 requests 
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originator 50 to validate the transaction via another e-mail message at 440. The 
e-mail message includes the UTID. 

The originator 50 validates transactions by comparing UTID with a 
list 100, including UTIDs generated by the originator along with associated 
information. The originator 50 sends a negative acknowledgment due to failure to 
match a UTID or associated information if the transaction is invalid or a positive 
acknowledgment if the transaction is valid and the UTID and associated 
information matches at 445. The TA 60 upon receipt of a positive or negative 
validation of the transaction with the associated UTID notifies the recipient of a 
positive status at 450. 

transmitting a request for delivery of said product to a delivery managing server 
(col. 6 lines 40-56), as disclosed by Talati through the functionality of: 

The delivery system between the client 10 and the merchant 20 can 
be a regular mail system, telephone system, computer network or any other 
delivery system like UPS or Federal Express. The delivery system between the 
client 10 and the merchant 20 must also have some tracking capability. The 
delivery system between the merchant 20 and the CCA 30 is typically a private 
network providing Point-Of-Sale (POS) processing. All necessary information is 
transferred between two or more points in this network with a tracking 
mechanism that can follow the transactions. All of the above steps can also be 
executed within electronic commerce transactions; 



• 
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The CA 60 responds at step 180, with an authorization for the 



transaction if the client 50 transaction and credit limit have been approved by the 
CA processor 61 and if there is a confirmation by client 10 of transaction validity. 
If the transaction is not validated by either the CA 60 or client 50, the CA 
transmits a rejection of the requested transaction to the merchant at step 185, 
and the client is notified by the merchant of the rejection at step 190. Upon 
confirmation of the purchase order, the merchandise may be delivered to the 
client 50 and a credit card transaction can be completed between client 50 and 
merchant 55 at step 195. 

transmitting a request for payment processing for said trading to a payment 
managing server (col. 6 lines 1-24), as disclosed by Talati through the functionality of: 



merchant 55, a CA processor 61 determines if the purchase order is authorized 
at step 100 by attending to the validity of the credit card number, merchant, 
amount of purchase, etc., and determine the client identity. The CA 60 transmits 
at step 165, the purchase order and the associated UTID 60 and purchase order 
data to the client processor 70. The UTID 60 and purchase order data are 
processed at the client 50 to determine if they are valid. The transmission from 
the CA 60 to the client 50 may be encoded using some type of virtual encryption 
key or any suitable encryption technology. The client processor 70 decodes the 
transmission (if encrypted) using knowledge of the virtual encryption key method 
between the client 50 and the CA 60 and compares the received unique 



Upon receipt of the payment authorization request from the 
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transaction identifier to a unique transaction identifier list 100 of identifiers 
transmitted from the client at step 170 to determine whether to validate the 
transaction. The results of the validation is then forwarded to the CA 60. If the 
UTID 60 matches an entry within the client list 100 and the purchase order data 
checks out with what the client 50 expects, the requested transaction is identified 
as valid. If no match for the UTID is found or if the purchase order data is 
incorrect the requested transaction is identified as invalid or fraudulent 

— The CA 60 responds at step 180, with an authorization for the 
transaction if the client 50 transaction and credit limit have been approved by the 
CA processor 61 and if there is a confirmation by client 10 of transaction validity. 
If the transaction is not validated by either the CA 60 or client 50, the CA 
transmits a rejection of the requested transaction to the merchant at step 185, 
and the client is notified by the merchant of the rejection at step 190. Upon 
confirmation of the purchase order, the merchandise may be delivered to the 
client 50 and a credit card transaction can be completed between client 50 and 
merchant 55 at step 195. 

Response to Arguments 

8. Applicants arguments filed 08/20/2002 have been fully considered but they are 
not persuasive. This Office Action is responding to applicant's arguments. Prior art 
used in the above rejection includes: 
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Talati (U.S. Patent No. 5903878) which discloses a method for providing 
validated electronic commerce transactions; and 

Wiecha (U.S. Patent No. 5870717) discloses the system enables an employee 
who needs an item which must be ordered from a supplier to select the item from an 
electronic catalog displayed on a personal computer and submit an order for approval 
and processing directly, by-passing both the normal paper approvals and the manual 
verification of the order by the organization's Purchasing department. 

Talati and Wiecha are prior art to the application of applicant that are both 
classified in the business art under 705/26. Examiner maintains that both are 
compatible art that present features/aspects that are complementary. Therefore, it 
would have been obvious to one skilled in the art at the time the invention was made to 
combine these prior art references to disclose applicant's invention. 



Applicants argue, on pg. 1-3,: 

that Talati merely discloses transaction processing and authentication that 
is decided at the time of ordering a product, not afterward when present status 
information would be exchanged. In this respect, in Talati, there is an exchange of 
information between an originator 50 and a recipient 55 using an e-mail delivery system 
305 (col. 1 1, lines 37-40 of Talati). The "delivery" referred to is the e-mail delivery 
system that is set forth by Talati with respect to the exchange of the information 
between the originator and recipient. On the other hand, Applicants' claimed invention 
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includes transmitting or managing present status of processing for delivery of a product 
corresponding to an order, which necessarily occurs after the order processing. 

The Examiner refers to Talati's e-mail system and further cites the 
disclosure by Talati that the e-mail delivery system provides a traceable delivery 
system. Further, as noted by the Examiner, Talati states that the e-mail delivery system 
may also be used to process complex transactions and safely share information 
between multiple entities (citing col. 8-, lines 21-25 of the reference). From this cited 
passage of Talati, the Examiner concludes that the reference discloses the processing 
of the present status of the delivery of the product corresponding to an order (see page 
33, lines 17-20 of the May 20, 2002 Office Action). This conclusion is not supported by 
the reference, however. 

Rather, one having ordinary skill in the art would view the disclosure of 
Talati as being silent in its disclosure with respect to disclosing the receiving or 
managing of present status of processing for processing initiated for an order including 
the present status of processing for delivery of the product corresponding to the order 
and present status of processing for payment for the trading. Therefore, at issue is 
whether one having ordinary skill in the art would find the differences between the 
invention as claimed and Talati obvious at the time of the invention. 

Examiner disagrees. Talati does disclose the receiving and managing of 
present status of processing for processing initiated for an order including the present 
status, as claimed by applicant, in the following disclosures: 
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(col. 5 line 50 - col. 6 line 60) verifying and validating various steps of 
transactions; 

(col. 8 line 62 - col. 9 line 1 1 ) A format of an e-mail record 330 is more fully 
described in FIG. 12 wherein there is shown an e-mail record 330 including the unique 
transaction identifier or message id 331; a mail type identification 335 indicating whether 
the record is to be transmitted, was just received, has already been transmitted, or 
comprise a transaction e-mail; the recipient's address 340; the subject matter of the 
e-mail 345; and the contents of the e-mail 348. For simplicity, the mail type 
identification 335 identifies the state of the e-mail record as it relates to the state of the 
e-mail delivery system 305. For example, when a user creates an e-mail record, the 
ECS 300 deposits this e-mail record into the mailbox database 315 with mail "type" 
equal to 1 indicating that the e-mail record is ready to be delivered to the recipients. 
The recipient address 340, subject matter 345 and contents 348 provide routing and 
content information to the e-mail delivery system 305. 

(col. 3 lines 4-59): 

A validated transaction is a transaction in which the TA validates the 
entities, facilitates the transaction and/or validates the contents of the transaction by the 
originator. In a validated electronic commerce transaction, either the client, merchant or 
transaction administrator can initiate the transaction. In a purchase transaction, the 
client initiates a transaction requesting particular items of merchandise or services from 
a merchant via the Internet, a dial-up-network, or any suitable network. The electronic 
transaction includes details of the transaction such as descriptions of the item(s) that 
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the client desires to purchase, credit card or check payment information, information on 
other types of payment by means of which the item(s) will be purchased, and a unique 
transaction identifier that has been generated by the originator and is uniquely 
associated with the particular purchase transaction. 

This information is transmitted to the merchant over the network. In 
response to the purchase order, the merchant generates a payment authorization 
request for transmission to the TA. The payment authorization request will have 
attached to it the unique transaction identifier initially provided by the client along with 
transaction information. Upon receipt of the payment authorization request the TA will 
validate the client and the merchant using the information provided. The TA then 
generates a validation request to the client that includes the unique transaction 
identifier. This communication between the TA and the client may be encrypted using a 
suitable encryption method or a set of virtual keys known only to the TA and each 
individual purchaser. 

Upon receipt of the validation request, the client decodes, if necessary, 
the encrypted validation request and extracts the unique transaction identifier therefrom. 
The identifier is compared to a listing of generated transaction identifiers at the client to 
confirm that the client authorized the transaction order with which the transaction 
identifier is associated. Confirmation or denial of the validation is transmitted back to 
the TA by the originator. This confirmation may be encrypted using a suitable 
encryption method, if necessary. To provide additional security, a query or group of 
queries may be included within the validation requests between the TA and the 
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originator. These queries are randomly generated and directed to information known 
solely by the originator, such as mother's maiden name, social security number, driver's 
license number, birth date, etc. 

Upon receipt of validation or non-validation from the originator, the TA 
confirms or aborts the transaction by notifying the recipient whether or not the 
transaction is valid based upon the originator's validation response and the accuracy of 
the information contained in the transaction request. If the information in the transaction 
request checks out, the item(s) ordered may be delivered to the originator by the 
recipient. The delivery and communication systems between the client, merchant and 
TA preferably consists of some type of computer network such as the Internet, private 
Intranet or any suitable network. 

Additionally, Wiecha discloses Purchaser can update status ofPO manually after 
receiving acknowledgements, status updates, etc. from vendors via fax, phone, or mail. 
Changes to the PO can then be saved to the DB2/2 database on the Purchasing Server 
(col. 9 lines 59-63) 

Therefore, examiner maintains the rejection. 



Applicants argue, on pg. 4, With respect to the delivery system disclosed by 
Talati, the Examiner refers to the Description of Related Art section of the patent that 
refers to Fig. 1. The commercial transaction flow chart shown in the figure merely sets 
forth the entities of a client 10, merchant 20 and payment authority 30. The delivery 
system is disclosed as having some tracking capability. However, Fig. 1 is not a figure 
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of the invention disclosed by Talati, but rather a description of the background art 
related to the invention. Therefore, there is no correspondence between the "delivery" 
described with respect to Fig. 1 (referring to coL 1, lines 56-65 of the reference) by 
Talati and the description provided in col. 8, lines 21-25 of the reference which the 
Examiner cites as describing the claimed present status of processing for delivery of the 
product Accordingly, Applicants maintain their position that Talati fails to describe the 
claimed receiving or managing of information including a present status of processing 
for delivery of a product corresponding to an order. 

Examiner disagrees. The disclosure of Talati includes descriptions of prior art. 
This does not relegate the prior art descriptions as inappropriate or unusable in the 
rejection. The referenced information is disclosed, and is identified as pertaining to old 
and well known art in Talati, predating the patent of Talati. The disclosure in fig. 1 and 
its description pertain to a general concept of on-line transaction processing that is 
related art to the invention of Talati, and the invention of applicant. Talati describes fig. 
1 as a common set-up for commercial (including electronic) transactions (col. 1 lines 24- 
25). The basic functionality of fig. 1 is included and expanded in the disclosures of 
Talati. The functionality, regardless that it is prior art to Talati, is disclosed appropriately 
in Talati, and can be used in a rejection of applicant's invention. Additionally, applicant 
failed to address the other referenced disclosures of Talati that examiner considered 
pertinent to and identified in the rejection of this claim language (see section 5 above). 

Therefore, examiner maintains the rejection. 
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Applicants argue, on pg. 5, Further, the present status of processing for 
payment processing for the trading is not disclosed by Talati. Rather, the e-mail 
message transmitted by the e-mail delivery system includes content 348 (Fig. 12) 
necessary to perform validation and authorization procedures at the credit authorities or 
transaction administrator and the transaction originating party. See col. 1 1 , lines 29-37 
of the reference. Thus, this information is not related to the present status of payment 
processing, but rather to authorization and validation with respect to the transaction 
being requested. 

Examiner disagrees. Examiner maintains that the disclosure of Talati discloses 
the present status of processing for payment processing in the disclosure: 

(col. 6 lines 1-24; col. 7 lines 25-63): 

Upon receipt of the payment authorization request from the merchant 55, 
a CA processor 61 determines if the purchase order is authorized at step 100 by 
attending to the validity of the credit card number, merchant, amount of purchase, etc., 
and determine the client identity. The CA 60 transmits at step 165, the purchase order 
and the associated UTID 60 and purchase order data to the client processor 70. The 
UTID 60 and purchase order data are processed at the client 50 to determine if they are 
valid. The transmission from the CA 60 to the client 50 may be encoded using some 
type of virtual encryption key or any suitable encryption technology. The client 
processor 70 decodes the transmission (if encrypted) using knowledge of the virtual 
encryption key method between the client 50 and the CA 60 and compares the received 
unique transaction identifier to a unique transaction identifier list 100 of identifiers 
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transmitted from the client at step 1 70 to determine whether to validate the transaction. 
The results of the validation is then forwarded to the CA 60. If the UTID 60 matches an 
entry within the client list 100 and the purchase order data checks out with what the 
client 50 expects, the requested transaction is identified as valid. If no match for the 
UTID is found or if the purchase order data is incorrect the requested transaction is 
identified as invalid or fraudulent. 

The CA 60 responds at step 180, with an authorization for the transaction 
if the client 50 transaction and credit limit have been approved by the CA processor 61 
and if there is a confirmation by client 10 of transaction validity. If the transaction is not 
validated by either the CA 60 or client 50, the CA transmits a rejection of the requested 
transaction to the merchant at step 185, and the client is notified by the merchant of the 
rejection at step 190. Upon confirmation of the purchase order, the merchandise may 
be delivered to the client 50 and a credit card transaction can be completed between 
client 50 and merchant 55 at step 195. 

Additionally, Talati discloses information that includes the aspect of present 
status of processing. Also, Talati discloses a specific example for an electronic check 
transaction using e-mail in the disclosure: 

(see col. 9 lines 32-44) In the case of an electronic check transaction, the mail 
contents 348 of the e-mail may comprise a number of items, depending on who the e- 
mail is from, and the data required to be extracted by the e-mail control system 300 of 
the receiving party. A transaction request from the originator 50 may include an 
account number, amount of the transaction, account reference, transaction reference, 
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and originator's personal information. A response from a recipient 55 may include 
account number information, account references, transaction references, and recipient's 
personal information. An e-mail message from the transaction administrator 60 may 
contain query information for the originator to obtain validation. 

The functionality of Talati discloses the claimed aspect of the present status of 
processing for payment processing for the trading. 

Therefore, examiner maintains the rejection. 



Applicants argue, on pg. 5-6, Talati is also silent with respect to the comparing 
of a trading identifier and an e-mail address included in the trading information and 
outputting a warning if they are not coincident, as recognized by the Examiner. In this 
regard, the Examiner relies upon Wiecha for disclosing that a purchaser can update the 
status of a PO manually after receiving acknowledgements, status, updates, etc. from 
vendors via fax, phone or mail. However, Wiecha does not disclose the status of the 
delivery of the product as in the present invention, which is received from the 
communication network through which the order for the product is transmitted. 
Therefore, the teaching and disclosure provided by Wiecha is limited with respect to 
suggesting the proposed modifications to Talati set forth by the Examiner to one having 
ordinary skill in the art. 

Examiner disagrees. Talati does disclose (at col. 3 lines 20-48) The identifier is 
compared to a listing of generated transaction identifiers at the client to confirm that the 
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client authorized the transaction order with which the transaction identifier is associated. 
This disclosure is additionally supported by Talati in the disclosures: 

(col. 2 lines 51-55) The present invention overcomes the foregoing and other 
problems with a method and apparatus enabling verification and validation of original 
"electronic commerce transactions" between one or more originators, recipients, and 
transaction administrators (TA). 

(col. 4 lines 52-6) The transaction request includes a unique transaction 
identifier (UTID) associated with the specific transaction request and originator identity 
(OID) to identify the originator 50 to a transaction administrator 60 

(col. 4 line 66 - col. 5 line 32) 

Recipient 55 first reviews the transaction request using a processor 75 
and generates a request for authentication of the originator 50 using the OID, UTID and 
the information content of the transaction request such as an amount or document 
name at step 80 to the transaction administrator. The transaction administrator 60 first 
validates the identity of recipient 55 and then the OID at step 85. If the OID is invalid, 
the transaction administrator 60 notifies the recipient 55 of the invalidity and the 
transaction is denied. If the OID is valid, the transaction administrator 60 determines 
the originator associated with the OID, transmits the transaction request and associated 
data to the originator 50 and requests that the originator validate the transaction request 
containing the UTID at step 90. The transaction administrator 60 may also validate 
transaction amounts and credit limits at this time or upon receiving a response for the 
originator 50. 
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The originator 50 validates the transaction by comparing at step 95 the 
UTID with a list 100 generated by the processor 70 of the originator listing the UTID 
associated with each transaction generated by the originator and notifying the 
transaction administrator 60 of the results. The list 100 also includes the details of the 
transaction (amount; parties, etc.) associated with the UTID which must also be 
validated by the originator 50. The transaction is granted or rejected by the transaction 
administrator 60 based on the comparison results at step 1 05. If the originator 50 does 
not validate the transaction at step 95, the transaction administrator 60 rejects the 
transaction at step 110 which invalidates the transaction. The originator is notified at 
step 115 of the invalidation of the transaction. Upon receipt of the transaction validation 
status from the originator 50, the transaction administrator 60 validates the originator 50 
and the transaction request at step 120, and notifies the recipient 55. The originator 50 
and recipient 55 then complete the transaction at step 125. 
col. 11 line 51 -col. 12 line 8: 

While the following is described with respect to an e-mail delivery system 
it should be realized that any type of delivery system would be useful. The originator 50 
sends a document including a UTID and originator identifier (01 D) to recipient 55 within 
an e-mail message at 430. Upon receipt of the e-mail message, the recipient 55 
forwards another e-mail message to the transaction administrator (TA) 60 at 435. The 
e-mail message includes the OID, UTID and document name. The TA 60 authenticates 
the OID of originator so a message can be transmitted to the originator. If OID does not 
authorize, the TA 60 sends a negative response to recipient 55 at 450. Otherwise, the 
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TA 60 requests originator 50 to validate the transaction via another e-mail message at 
440. The e-mail message includes the UTID. 

The originator 50 validates transactions by comparing UTID with a list 100, 
including UTIDs generated by the originator along with associated information. The 
originator 50 sends a negative acknowledgment due to failure to match a UTID or 
associated information if the transaction is invalid or a positive acknowledgment if the 
transaction is valid and the UTID and associated information matches at 445. The TA 
60 upon receipt of a positive or negative validation of the transaction with the associated 
UTID notifies the recipient of a positive status at 450. 

Examiner asserts that these disclosures encompass applicants' argument for 
comparing of a trading identifier and an e-mail address included in the trading 
information and outputting a warning if they are not coincident. 

Therefore, examiner maintains the rejection. 



Applicants argue, on pg. 6, Despite the limited teaching provided by Wiecha, 
the Examiner states that the combination of Talati and Wiecha provides the functionality 
of receiving the status of the delivery of the product in the present invention (see page 
33, line 20 - page 34, line 2 of the Office Action). However, this reason does not provide 
a proper motivation for combining the Talati and Wiecha references to suggest the 
modification to Talati required in the rejection. Therefore, the 35 U.S.C. §103 rejection 
of the claims based on Talati and Wiecha should be withdrawn. 

Examiner disagrees. Prior art used in the above rejection includes: 
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Talati (U.S. Patent No. 5903878) which discloses a method for providing 
validated electronic commerce transactions; and 

Wiecha (U.S. Patent No. 5870717) discloses a system that enables an employee 
who needs an item which must be ordered from a supplier to select the item from an 
electronic catalog displayed on a personal computer and submit an order for approval 
and processing directly, by-passing both the normal paper approvals and the manual 
verification of the order by the organization's Purchasing department. 

Talati and Wiecha are both prior art that are classified in the business art under 
705/26, the same as applicant's invention. Both disclose a system and method for 
purchasing/procuring items or products. Examiner maintains that both are compatible 
art that present features/aspects that are complementary and in the class of on-line 
purchasing of products, and associated actions necessary to complete the transaction. 
Therefore, it would have been obvious to one skilled in the art at the time the invention 
was made to combine these prior art references to disclose applicant's invention. 

Examiner maintains the rejection. 



Conclusion 

9. THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
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TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

1 0. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Forest O. Thompson Jr. whose telephone number is 
(703) 306-5449. The examiner can normally be reached on 6:30-3:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Wynn Coggins can be reached on (703) 308-1344. The fax phone numbers 
for the organization where this application or proceeding is assigned are (703) 872-9326 
for regular communications and (703) 872-9327 for After Final communications. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is (703) 305- 
3900. 
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